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(54) System and method for generating, transferring and using an annotated universal address 



(57) A system enables a user to maintain a catalog 
of network objects of interest to the user. The system 
comprises a diary owner system, a diary server and con- 
tent providers, each coupled to a computer network. 
Each content provider includes presentable objects, an- 
notated universal addresses which identify the objects 
and have annotations for controlling aspects of the ob- 
jects or addresses, and transfer scripts enabling the 
transfer of the annotated universal addresses to the di- 
ary server. The diary server maintains the annotated 



universal addresses and presentation context informa- 
tion for subsequent retrieval. Accordingly, a diary owner 
or other user can access the annotated universal ad- 
dresses and presentation context information to present 
the diary. Since content providers generate the annota- 
tions within the annotated universal addresses, the con- 
tent provider can control aspects of the objects from 
within the user's diary. Since the presentation context 
information is separated fmm the content, presentation 
context can easily be modified. 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0001] This invention relates generally to computer 
networks, and more particularly provides a system and 
method for generating, transferring and using annotated 
universal addresses which can be presented by multi- 
media presentation tools, including internet browsers. 

2. Description of the Background Art 

[0002] One of the latest means of communication to 
obtain truly widespread acceptance is the medium 
known as the Internet. A global network, connecting mil- 
lions of computers, the Internet is rapidly becoming the 
'ultimate' way of communication. Still, it has quite a few 
drawbacks. Some, like its speed (or lack thereof), are 
readily apparent to the regular user. 
[0003] In real life, we (consciously or unconsciously) 
'judge a book by its cover*, i.e. , we form an opinion about 
other people based on how they present themselves, 
through their style of clothing, the car they drive, their 
hobbies and interests, and the people they admire or 
detest. Users of the Internet find it virtually impossible 
to present themselves, other than through what they 
'say' in email, on newsgroups, etc. Technical users have 
some ability to present themselves through their web 
sites. However, setting up and maintaining such a pres- 
ence on the web requires talents from many deferent 
disciplines, including Computer Science, Human-Com- 
puter Interface design, graphic design, fine art, and writ- 
ing. It is obvious from many examples available on the 
web today, that not all users have all of these skills in 
equal proportions. As such, the Internet is essentially a 
faceless medium, meaning you hardly know who you're 
dealing with. 

[0004] In the real world, when we visit a place we like, 
we often take home some tangible memory of that place, 
like photographs or souvenirs. On the web, we don't re- 
ally have that option. The only 'memories' we might have 
of where on the web we have been last week, are some 
rather inexpressive bookmarks that say 'Welcome to 
the homepage of SomeCompany" (or even worse: http: 
//www. somecompany.com/). Such references give us 
no (sensory) clue whatsoever as to why we liked that 
particular place on the web, and whether or not we might 
like to vise it again in the future. In this sense, our ex- 
ploits on the web are rather volatile; i.e. we don't have 
anything 'tangible' by which to remember our travels. 

SUMMARY OF THE INVENTION 

[0005] Particular and preferred aspects of the inven- 
tion are set out in the accompanying independent and 
dependent claims. Features of the dependent claims 



may be combined with those of the independent claims 
as appropriate and in combinations other than those ex- 
plicitly set out in the claims. 

[0006] The present invention provides a system and 

s method for generating, transferring and using annotated 
universal addresses which can be presented by multi- 
media presentation tools, including internet browsers. 
[0007] The system and method enable a user to main- 
tain an ordered set of network object links (annotated 

10 universal addresses or AUAs) in an AUA database. The 
contents of the AUA database are presented to the user 
within a presentation context (e.g., template format). 
The system allows the user to select a different presen- 
tation context without effecting the contents of the AUA 

is database. One of the types of presentation contexts is 
organized like a diary or agenda. Each context may in- 
clude theme sections (e.g., car section, sport section, 
personal finance section, etc.) and sections per day. All 
of the sections optionally may be organized by time. 

20 [0008] The system comprises a server which acts 
both as the AUA database server and as a presentation 
context server. Alternatively, this server may be divided 
into two separate servers. The system further includes 
an owner system and content providers. Each content 

25 provider includes descriptions of presentable objects, 
AUAs which identify the location of the objects (the uni- 
versal address part of the AUA) and have annotations 
for controlling aspects of the objects. Each content pro- 
vider also includes transfer scripts enabling the transfer 

30 of the AUAs to the AUA database server. The AUA da- 
tabase and presentation context server maintains the 
AUAs in a per user AUA database and maintains tem- 
plate formats (presentation contexts that are to be 
shared by all users that have selected the same pres- 

35 entation context for their AUA database) for subsequent 
retrieval. Accordingly, the AUA database owner or other 
user can access the AUAs and the template information 
to have the AUAs presented. Since content providers 
have defined the annotations within the AUA, the con- 

40 tent provider controls certain aspects of the objects as 
they are presented to the owner and any other user. 
[0009] One embodiment provides a method which in- 
cludes the steps of receiving a request from a client for 
both an AUA database and an associated presentation 

45 context, identifying the template and AUA database cor- 
responding to the request, the annotated universal ad- 
dress including a universal address identifying a loca- 
tion of an object and including an annotation for control- 
ling an aspect of the object, and transmitting the format 

50 information and the annotated universal address to the 
client. 

[001 0] Another embodiment provides a method which 
includes the steps of requesting access to an AUA da- 
tabase on a server, receiving format information and an 
55 annotated universal address from the server, the anno- 
tated universal address including a universal address 
identifying a location of an object and including an an- 
notation for controlling an aspect of the object, generat- 
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FIG. 6 illustrates a window requesting a diary server 
address tor storing a requested AUA; 
FIG. 7 is a block diagram illustrating a message 
packet created by the transfer script of FIG. 1 ; 
5 FIG. 8 illustrates a window requesting the section 
name in which to store A received AUA; 
FIG. 9 illustrates a window of the car section of user 
diary data; 

FIG. 1 0 is a flowchart illustrating a method of adding 
10 an AUA to the diary server, in accordance with the 
present invention; 

FIG. 11 is a flowchart illustrating a method of using 
AUAs to generate diary web pages for a section; 
FIG. 12 is a flowchart illustrating a method of gen- 
15 erating an AUA; 

FIG. 1 3 is a block diagram illustrating details of user 
diary data; 

FIG. 14 illustrates a window enabling a diary owner 
system to input an object to be included in an an- 

20 notated universal address; 

FIG. 1 5 illustrates a window enabling a diary owner 
to input annotations to be associated with the object 
and included in the annotated universal address; 
FIG. 16 is a block diagram illustrating transfer op- 

25 erations in a first embodiment; and 

FIG. 17 is a block diagram illustrating transfer op- 
erations in a second embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED 
30 EMBODIMENT 



ing network data using the format information and the 
AUA, and retrieving the object specified by the universal 
address part of the AUA. 

[0011] Yet another embodiment provides a method 
which includes the steps of specifying a universal ad- 
dress to identify a location of an object, generating an 
annotation for controlling an aspect of the object, asso- 
ciating the universal address with the annotation to gen- 
erate an annotated universal address, associating a re- 
quest interface with the annotated universal address, 
generating network data for presenting the object and 
the request interface, and enabling transfer of the anno- 
tated universal address upon receiving an indication at 
the request interface. 

[0012] Still another embodiment provides a method 
which includes the steps of requesting addition of an an- 
notated universal address to an AUA database on a 
server, receiving a transfer script in response to the re- 
quest, initiating execution of the transfer script to re- 
quest a transfer applet from the server, and initiating ex- 
ecution of the transfer applet to transfer the annotated 
universal address to the AUA database on the server. 
[0013] The system and method of the present inven- 
tion may advantageously enable a user to maintain an 
AUA database and a presentation context associated 
with it. This enables a user to maintain for instance a 
more exciting catalog ( "diary", "agenda" or any other 
presentatbn context) of web sites or objects available 
from the web sites. The system and method enable the 
diary owner to provide other user's with access to the 
owner's AUA database and presentation context. The 
system and method enable a diary owner to change for- 
mats among several available formats. The system and 
method enable a content provider to create AUAs for 
objects at his web site, to have these AUAs transferred 
from the web site by a user to the user's database, and 
to have a new access path to the object from within the 
presentation context associated with the user's data- 
base. The system and method advantageously enable 
a content provider to target more appropriate users with 
advertisements. The system and method enable a con- 
tent provider to maintain some control of the objects dis- 
played at the user's diary. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] 

FIG. 1 is a block diagram illustrating a network sys- 
tem, in accordance with the present invention; 
FIG. 2 is a block diagram illustrating a computer 
system of FIG. 1; 

FIG. 3 is a block diagram illustrating details of an 
AUA of FIG. 1; 

FIG. 4 is a block diagram illustrating details of the 
diary applet of FIG. 1; 

FIG. 5 illustrates an example web page provided by 
a content provider of FIG. 1 ; 



[0015] FIG. 1 is a block diagram illustrating an exam- 
ple network system 1 00 in accordance with the present 
invention. The network system 100 includes a diary 

35 owner system 1 05 coupled via a computer network 1 1 0, 
e.g., the Wide Area Network (WAN) commonly referred 
to as the Internet 110, to a content provider 115. A diary 
server 120 and a viewer system 125 are also coupled 
to the computer network 1 1 0. The diary owner 1 05 main- 

40 tains a computer diary on the diary server 120. The con- 
tent providers 115 use annotated universal addresses 
to control aspects of the diary content. 
[001 6] The content provider 1 1 5 is a computer system 
that stores content data 130 for browsers to use. The 

45 content data 1 30 includes object information 1 32, which 
may be an image, text, a movie, an applet, etc., or a link 
thereto, for browsers to present. It is intended herein that 
the term "presenting" cover displaying, performing, ma- 
nipulating or other multimedia action performed by a 

so browser. The content data 1 30 further includes annotat- 
ed universal addresses (AUAs) 1 34 which both identify 
a universal address (URL) of the object information 1 32 
and specify aspects of how the universal address or ob- 
ject information 1 32 should be handled by the diary serv- 

55 er 120 or user. AUAs 134 will be described in greater 
detail wrth reference to FIG. 3. The content data 1 30 fur- 
ther includes a transfer script 136 that, when executed 
by the browser 1 42, enables the transfer of the an AUA 
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134 to the diary server 120. tt will be appreciated that 
sending the AUA 134 to the diary server 120 enables 
the content provider 1 1 5 to control aspects of the result- 
ing object as they are presented to the owner and any 
other user (in the presentation context specified by the 
template). The content provider 115 further includes a 
content provider (CP) server 1 29, which has a web serv- 
er (not shown) for communicating with a browser, and 
includes an AUA generator 1 40 for generating the AU As 
1 34. The AUA generator 1 40 is described in greater de- 
tail with reference to FIG. 12. Alternative to an AUA gen- 
erator 140 on the content provider, the AUA generator 
1 40 may be stored on the diary server 1 20 and executed 
thereon. 

[0017] The diary server 120 is a computer system 
which includes diary software 120, which has a web 
server (not shown) for communicating with a browser 
and with the content provider 115. The diary software 
120 receives the AUAs 134 being transferred from the 
content provider 115, and stores them in an AUA data- 
base (labeled AUAs) 156 in user diary data 146. User 
diary data 146 also includes a template identification 
(ID) 154, which specifies a template 150 stored in the 
diary server 120. Each template 150 identifies a format 
for diary pages, and identifies objects (such as cartoon 
characters, company advertisements, etc.) to be pre- 
sented on the diary pages. It will be appreciated that the 
templates 150 may alternatively be stored on a presen- 
tation context server (not shown) in communication with 
the diary server 120. For example, a template 150 may 
be created by a particular corporation wanting to adver- 
tise and thus offering a presentation context for a user 
to select. The template 1 50 may be stored on a presen- 
tation context server operated by the corporation and 
downloaded in accordance with the template ID 154 in 
the page definition. It will be appreciated that, although 
the embodiment is being described as using templates 
150, any means for presenting data in a presentation 
context may be used. User diary data 146 is described 
in greater detail with reference to FIG. 13. 
[0018] The diary server 120 further includes a diary 
applet 1 48, which may be downloaded via the computer 
network 1 1 0 to any browser for presenting the user diary 
data 146. The diary applet 148 is described in greater 
detail with reference to FIG. 4. Although the system 100 
is being described with reference to Java applets, it will 
be appreciated that any executable or interpretable ap- 
plication code, which is downloaded from a source com- 
puter and run on a destination computer, may alterna- 
tively be used. Other downloadable code may include 
JavaScript™ scripts developed by Netscape Communi- 
cation, Inc., ActiveX™ controls designed for use in the 
ActiveX™ distributing environment developed by the 
Microsoft Corporation, visual Basic also developed by 
the Microsoft Corporation, plugins which add to the func- 
tionality of an already existing application program, etc. 
It will be further appreciated that one or more applets, 
one or more ActiveX controls, one or more plugins, etc. 



or combinations thereof may alternatively be used. The 
term "applet" is being used herein to include any down- 
loadable code format. 

[0019] The diary owner system 105 is a computer sys- 
s tern which stores and operates a browser 142, such as 
the Netscape Navigator browser by Netscape Corpora- 
tion or the Internet Explorer browser by Microsoft Cor- 
poration. To initiate a diary presentation context, the di- 
ary owner system 105 via the browser 142 contacts the 

10 diary server 1 20 to open a user database, and to select 
a template 150 (i.e., a presentation context or format). 
The diary software 1 44 (which may be implemented as 
one or more applets) allows the user to select a partic- 
ular section, to browse through various sections, to 

15 show a particular AUA, etc. For each page, the diary 
software 144 generates a page definition using a net- 
work-based publishing language (NBPL) such as HTML 
and instructs the browser to present the page corre- 
sponding to the page definition to the user. 

20 [0020] The diary owner system 105 via the browser 
1 42 contacts a content provider 1 1 5 to view content data 
130, or more particularly to view the object information 
132. If the user of the diary owner system 105 decides 
that object information 1 32 is worthy of adding to the 

25 diary on the diary server 120, the user may provide an 
indication of interest to a request interface, e.g., by per- 
forming a mouse<lown event while the mouse pointer 
is over a virtual button on the web page provided by the 
content provider 115. Accordingly, the content provider 

30 115 transfers the AUAs 1 34 corresponding to the user's 
selection to the diary server 1 20. Since an applet is lim- 
ited to setting up a communications link with only the 
originator of the applet, it will be appreciated that trans- 
ferring the AUA 1 34 to the diary server 1 20 may include 

35 a level of indirection. That is, the content provider 115 
via the CP server 129 may forward a transfer script 1 36 
to the browser 1 42 on the diary owner system 1 05. The 
browser 142 executes the transfer script 136, which 
generates a request (e.g., a post request) for the diary 

40 server 1 20 to download a transfer applet 151. It will be 
appreciated that the request may be implemented by 
generating a web page containing the request. The 
transfer applet 151 can establish a communications link 
with the diary server 1 20 (for storage of the new AUAs, 

45 e.g., as part of a storage operation of the full user diary 
data 1 46) and can establish a communications link with 
the diary applet 148 on the diary owner system 105 to 
point out the newly added AUAs 156 (for immediate 
presentation at the diary owner system 105). 

50 [0021] The diary owner system 105 via the browser 
142 or the viewer system 125 via the browser 1 58 may 
contact the diary server 120 to request viewing particu- 
lar user diary data 1 46. The diary software 144 uploads 
the user diary data 146, the diary applet 148 and the 

55 appropriate template 1 50 to the requesting browser 1 42, 
158. The requesting browser 142, 158 executes the di- 
ary applet 148, which generates HTML data 'on the fly' 
from the template 1 50 and from the AUAs 1 56 contained 
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in the requested user diary data 146. It will be appreci- 
ated that the diary server 120 enables the diary owner 
system 105 to select different templates 150 on the fly, 
so that a different diary formats can be used. Generating 
the HTML data from AU As is described in greater detail 
with reference to FIG. 11. Representative organization 
of the user diary data 1 46 is illustrated in and described 
with reference to FIG. 13. It will be further appreciated 
that the viewer system 1 25 exemplifies any system con- 
nected to the computer network 110 that includes a 
browser. 

[0022] FIG. 2 is a block diagram illustrating a compu- 
ter system 200 which illustrates details of each of the 
diary owner system 105, the content provider 115, the 
diary server 120 and the viewer system 125. The com- 
puter system 200 includes a processor 205, such as an 
Intel Pentium microprocessor or a Motorola Power PC 
microprocessor, coupled to a communications channel 
220. The computer system 200 further includes an input 
device 210 such as a keyboard and mouse, an output 
device 215 such as a Cathode Ray Tube (CRT) display, 
a communications device 225, data storage 230 such 
as a magnetic disk, and working memory 235 such as 
Random-Access Memory (RAM), each coupled to the 
communications channel 120. The communications 
channel 220 is coupled to the computer network 110. 
One skilled in the art will recognize that, although the 
data storage 230 and working memory 235 are illustrat- 
ed as separate units, data storage 230 and working 
memory can be integrated or partially integrated units. 
[0023] An operating system 240 controls processing 
by the processor 205, and is typically stored in data stor- 
age 230 and loaded into working memory 235 (as illus- 
trated) for execution. Other programs or data 255 such 
as browsers, servers, applets, scripts, content data, etc. 
may also be loaded into working memory 235 (as illus- 
trated) for execution by processor 205. The programs 
or data 255 may be loaded via the communications in- 
terface 225 of via the data storage 230. One skilled in 
the art will also recognize that the programs or data 255 
may be received by and stored in the system in alterna- 
tive ways. For example, a computer-readable storage 
medium (CRSM) reader 245 such as a floppy disk drive, 
hard disk drive, CD-ROM reader, magneto-optical read- 
er, CPU (for RAM), etc. may be coupled to the commu- 
nications channel 220 for reading a computer-readable 
storage medium (CRSM) 250 such as a magnetic disk, 
a hard disk, a magneto-optical disk, RAM, etc. Accord- 
ingly, the system 200 may receive programs or data 255 
via the CRSM reader 240. 

[0024] One skilled in the art will recognize that the 
computer system 200 may also include additional infor- 
mation, such as network connections, additional mem- 
ory, additional processors, LANs, input/output lines for 
transferring information across a hardware channel, the 
Internet or an Intranet, etc. 

[0025] FIG. 3 is a block diagram illustrating details of 
an AU A 300, such as the AUA 1 34 stored on the content 



provider 115. The AUA 300 includes an object-specific 
universal address (e.g., a uniform resource locator or 
URL) 305, which identifies object information 1 32 such 
as an image, text, applet, etc. The AUA 300 further in- 

s eludes annotations 307, which indicate how to handle 
some aspect of the object information 1 32 or the univer- 
sal address 305. The example annotations 307 listed 
include expiration data 310 defining the date which the 
content provider 115 no longer guarantees the exist- 

10 ence of the object, re-exportation data 315 indicating 
whether the content provider 115 enables the diary ap- 
plet 148 to export the AUA 156 from the diary server 120 
exactly as the content provider 115 exported the AUA 
134 in the first place, and link data 320 indicating a de- 

15 sired hypertext link. It will be appreciated that in order 
for the diary applet 1 48 to be able to re-export the AUA 
156, the diary applet 148 should contain the same or 
similar transfer scripts as were part of the content pro- 
vider 115 in transfer script 136 and should be able to 

20 display the same or similar request interface as the orig- 
inal content provider 115. It will be further appreciated 
that the link data 320 may include a link to an object or 
page which may be on a different site than the content 
provider site 115. 

25 [0026] Other annotations 307 may include a suggest- 
ed section in which to store the AUA 134 on the diary 
server 120, a natural size for the object, a description of 
the object, a privacy level, a type of object indicator, etc. 
It will be appreciated that the annotations 307 may over- 

30 ride HTML default parameters. It will be further appre- 
ciated that the AUA 156 on the diary server 154 may 
have some differences from the corresponding AUA 1 34 
on the content provider 115, such as the removal of the 
suggested section in which to store the AUA 134 after 

35 the AUA 134 has been stored in a section. It will be still 
further appreciated that the AUA 1 34 may include a field 
to indicate whether the AUA 1 34 is optional or to be pre- 
sented based on certain criteria. For example, the AUA 
134 may include a privacy level indicating that the AUA 

40 134 should not be presented unless the user has the 
same privacy level or higher The privacy level may be 
set by the content provider 1 1 5 or may be defined by the 
user based on a response to a query. As another exam- 
ple, the AUA 134 may include an optional field which 

45 enables the user to decide whether the AUA 134 is to 
be presented. That is, the diary applet 1 48 may ask, "Do 
you wish to see a picture of the car to win the latest race? 
• Presentation of the AUA 1 34 may be based on the re- 
sponse. 

50 [0027] FIG. 4 is a block diagram illustrating details of 
the diary applet 148, which includes code for generating 
web pages to present the user diary data 1 46. The diary 
applet 1 48 includes a section manager 405 for retrieving 
the template 150 (i.e., a presentation context) corre- 

55 sponding to the template ID for a section. It will be ap- 
preciated that the section manager 405 enables a user 
to select a section (e.g., the car section as illustrated in 
and described with reference to FIGs. 9 and 1 3 or a sec- 
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tion for a given calendar date). 
[0028] The section manager 405 initiates each of the 
modules 407 corresponding to the annotations 307 con- 
tained in the AUAs 156. That is, the expiration module 
410 examines the expiration data 31 0 to determine if the 
All A 156 has expired. If expired, then the expiration 
module 41 0 informs the section manager 405 to discard 
the AUA 156. The re-exportation module 415 examines 
the re-exportation data 315 to determine if the AUA 1 56 
is to be exportable by a viewer, such as by the viewer 
system 125. If so, then the re-exportation module 415 
sends data and/or code to the section manager 405 to 
enable re-exportation. The link module 420 examines 
the link data 320 to determine if any hypertext links are 
desired. If so, the link address is provided as a hypertext 
link or as another connection means. The link module 
420 accordingly provides data and/or code to the sec- 
tion manager 405. Other modules for handling other an- 
notations, such as natural size, description, privacy lev- 
el, etc. may also be included. 

[0029] The section manager 405 compiles the pres- 
entation context based on the template 1 50 and the cur- 
rently selected section, the universal address parts of 
the AUAs 156 for the section and the information re- 
ceived from the modules 407 to generate an HTML page 
definition. The section manager 405 then instructs the 
browser 142, 158 to present the page corresponding to 
the page definition to the user. The browser 142, 158 
downloads the object information 132 specified by the 
universal address parts of the AUAs 156. 
[0030] The diary applet 1 48 optionally may include an 
AUA generator 425, similar to the AUA generator 140 
of FIG. 1 and described in greater detail with reference 
to FIG. 1 2. The AUA generator 425 enables a diary own- 
er system 105 to add AUAs that do not originate from 
the content provider 11 5 to the user diary data 146. FIG. 

1 4 illustrates a window 1 400 enabling a diary owner sys- 
tem 1 05 to input an object, such as text, an applet, an 
image, a movie, etc. into the system 105. Window 1400 
includes a box 1 405 for inputting the address identifying 
the codebase of the object (e.g. , applet), and a box 1 41 0 
for inputting an address identifying the object code (e. 
g., the applet code). Window 1400 further includes box 
1 41 5 for inputting a width annotation and a box 1 420 for 
inputting a height annotation. Button 1425 causes the 
window 1 500 for inputting additional annotations of FIG. 

1 5 to pop up. FIG. 1 5 illustrates a window 1 500 enabling 
a diary owner system 1 05 to input annotations to be as- 
sociated with the object added in FIG. 14. Window 1500 
includes a box 1505 for inputting additional annotations 
to the annotated universal address. The diary owner 
system 1 05 can then transfer the generated AUA to user 
diary data 146 in a manner similar to that described 
herein with reference to the transfer script 136. 
[0031] FIG. 5 illustrates an example web page 500 
provided by a content provider 1 1 5 implementing an em- 
bodiment of the present invention. In this example, the 
browser 142 displays the URL address (e.g., http:// 



somecompany.com) of the content provider 115 in win- 
dow portion 505 and displays the content data 1 30 in 
window portion 510. The example content data 130 of 
FIG. 5 includes a car object 515, a car "ADD - button 
5 520, a house object 525 and a house "ADD" button 530. 
It will be appreciated that this content provider 115 may 
provide sales information for cars and homes. The diary 
owner 105 may want to add the car object 515 into the 
diary, and more particularly to a car section in user diary 
data 146. The owner is not aware that this will in fact 
transfer an AUA 1 34 that corresponds to the car object 
and that the AUA 1 34 contains a universal address and 
one or more annotations. Accordingly, the user via the 
browser 142 clicks on car ADD button 520, thereby ini- 
tiating the transfer script 136. 

[0032] FIG. 6 illustrates a window 600 requesting a 
diary server 1 20 address at which to store the requested 
AUA 1 34. The window 600 includes an input box 605 
for inputting the usemame of the diary user, and a host 
box 610 for inputting the network address of the diary 
server 120. The browser 142, executing the transfer 
script 136, uses the username and network address to 
transfer the requested AUAs 1 34 via the computer net- 
work 110 to the diary server 120. Any transfer mecha- 
nism may be used. 

[0033] FIG. 7 is a block diagram illustrating a mes- 
sage packet 700 created by the transfer script 1 36 for 
transmission to the diary server 120. The message 
packet 700 includes the host address received in host 
box 610, the username 710 received in user box 605, 
the requested AUA 1 34 and other data 715 used for net- 
work transfer. The browser 142 establishes a commu- 
nications link with the diary server 1 20, and forwards the 
message packet 700 to the diary server 120. 
[0034] FIG. 8 illustrates a window 800 requesting the 
section name in which to store the received AUA 134. 
That is, the transfer applet 151 delivers the message 
packet 700 from the browser 1 42 on the diary owner sys- 
tem 105 to a particular AUA database within the user 
diary store 146. The transfer applet 151 retrieves the 
section names identifying the sections created for this 
user, and if requested by the AUA 1 34 offers the sug- 
gested section name as an option. It will be appreciated 
that, to offer the suggested section, the transfer applet 
151 itself must include a suggested section module (not 
shown) similar to the modules 307. The suggested sec- 
tion module would determine whether the AUA 134 in- 
cludes suggested section data and how to handle the 
suggested section data whether the option is selected 
or not. The browser 142 and diary software 144 enable 
the selection of a section. In this example, the browser 
142 and transfer applet 151 enable the selection of a 
previously created car section or a default created to- 
day's date section. 

[0035] FIG. 9 illustrates a page of the car section 900 
of user diary data 146. The URL address Chttp://diar- 
yserver.com/username) is shown in a window portion 
905 and the car section of user diary data 1 46 is shown 
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in object window 910. In this example, object window 
91 0 displays a first object 915 (which may be the object 
515 added from the content provider 115 example of 
FIG. 5). Object window 910 may include other objects, 
such as a second object 920 and a third object 925. The 
second object 920 may be, for example, an object from 
a blue book provider and the third object 925 may be, 
for example, an object from a particular car dealer. It will 
be appreciated that the car section 900 may also display 
an advertisement (e.g. , a cola drink) in an advertisement 
window portion 930 generated by the template 1 50. That 
is, the sponsor of the particular template 1 50 for this sec- 
tion may have built a link to an advertisement into the 
template 1 50. 

[0036] Generally, the section manager 405 of the di- 
ary applet 148 retrieves the selected template 150, 
which in this case includes a diagonal pattern of object 
locations. The section manager 405 of the diary applet 
148 retrieves the first AUA 156 for the first object loca- 
tion. In this case, the first AUA 1 56 identifies the car ob- 
ject 51 5. The expiration module 41 0 determines that the 
object has not expired. Thus, the section manager 405 
creates HTML data for instructing the browser 145 to 
download from the content provider 1 1 5 the object infor- 
mation 1 32 located at the object-specific URL 305. It will 
be appreciated that the specific image defined by the 
object information 1 32 may have changed since the re- 
quest to add the object to the diary server 120 took 
place. Accordingly, the content provider 115 can modify 
each day's, week's, etc. object. This will be appreciated 
for instance in cases where the object corresponds to 
an advertisement or a cartoon. The other annotation 
modules 407 review the annotations 307 contained in 
the AUA 1 56, and provide results to the section manager 
405. Based on the object information 132, the template 
150 (including any permanent or linked advertisements) 
and the results, the section manager 405 constructs the 
network-based publishing language (NBPL) page defi- 
nition such as an HTML page definition containing ob- 
ject-specific URLs 305 for the browser 1 42 or 1 58 to use. 
The diary applet 1 48 repeats the process for each of the 
AUAs 1 56, and stacks them accordingly into the object 
locations of the template 1 50. The section manager 405 
then instructs the browser 142 to present the page (cor- 
responding to the page definition) to the user. Generat- 
ing a section window 900 is described in greater detail 
with reference to FIG. 11. 

[0037] FIG. 10 is a flowchart illustrating a method 
1 000 of adding an AUA 1 34 to the diary server 1 20. The 
method 1000 begins with the diary owner system 105 in 
step 1005 using the browser 142 to establish a commu- 
nications link with the content provider 1 1 5. The content 
provider 115 in step 1010 uploads the content data 1 30 
to the browser 1 42, which in step 1015 presents the ob- 
ject. It will be appreciated that the step of presenting may 
include the step of displaying, the step of performing, 
the step of manipulating, or like browser action. The di- 
ary owner 105 in step 1020 requests the addition of the 



object to the diary server 1 20. That is, the user performs 
an action such as a mouse down event over a button to 
indicate a desire to add an object link to user diary data 
146. The browser 142 in step 1025 recognizes the ac- 

s tion and initiates execution of the transfer script 1 36. The 
transfer script 1 36 and transfer applet 1 51 in step 1030 
transfer the AUA 1 34 to the diary server 1 20. Step 1030 
may include the steps of requesting the diary server 1 20 
address, requesting the user's usemame, requesting a 

10 section name, and transmitting a message packet 700 
which includes the diary server address, the username 
and the AUA 1 34 to the diary server 1 20. The transfer 
applet 1 51 in step 1 035 stores the AUA 1 34 into the ap- 
propriate section of user diary data 1 46. Step 1 035 may 

is include the step of querying the user to select a previ- 
ously created or preferred section. Method 1000 then 
ends. 

[0038] FIG. 11 is a flowchart illustrating a method 
1100 of using AUAs 156 to generate diary web pages. 

20 Method 1 1 00 begins with the browser 1 58 on the viewer 
system 125 in step 1105 establishing a communications 
link with the diary software 144 on the diary server 120. 
The diary software 144 of the diary server 120 in step 
1110 sends a diary applet 148 and user diary data 146 

25 to the browser 1 58. The section manager 405 of the di- 
ary applet 148, being executed by the browser 158, in 
step 1115 selects a default "start" section, e.g., the car 
section. The section manager 405 in step 1120 obtains 
the template 1 50 and the AUAs 156 for the current sec- 

30 tion. FIG. 13 is a block diagram illustrating details of user 
diary data 146. As shown, the user diary data 146 is di- 
vided into user-specific databases, namely, database 
1 301 for user #1 and other database 1 302 for the other 
users. The database 1301 for user #1 includes a tem- 

35 plate ID 1310 and an AUA database 1 31 5. The AUA da- 
tabase 1 31 5 includes a car section 1 320 which contains 
AUAs 1 335, a sport section 1 325 which contains AUAs 
1 340 and a calendar date section 1 330 which contains 
AUAs 1 345. Thus, the section manager 405 can retrieve 

40 the appropriate template ID and AUAs easily. 

[0039] The section manager 405 in step 1 1 25 selects 
a first AUA 156. Assuming that the AUA 156 has expi- 
ration data, the expiration module 41 0 of the diary applet 
1 48 in step 1 1 30 determines if the AUA 1 56 has expired. 

^5 |f expired, the expiration module 410 instructs the sec- 
tion manager 405 in step 1 1 60 to discard the AUA 1 56. 
Alternatively, the section manager 405 in step 1 1 60 can 
replace the expired AUA 1 56 with a new object that does 
not correspond to the expired AUA 156. Method 1100 

50 then jumps to step 1155. Otherwise, the section man- 
ager 405 in step 1135 retrieves the object information 
1 32 specified by the object-specific URL 305 in the AUA 
156. The section manager 405 in step 1140 selects a 
first annotation 307. The section manager 405 in step 

55 1 1 45 instructs the appropriate module 407 to handle the 
aspect of the object accordingly. For example, if the first 
annotation 307 identified that re-exportation of the AUA 
156 is allowed, then the re-exportation module 415 
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sends a re-exportation button and a corresponding 
script to the section manager 405. The section manager 
405 in step 1150 determines if the AUA 156 includes 
another annotation to examine. If so, then method 1 1 00 
returns to step 1 140. Otherwise, method 1 1 00 proceeds s 
with step 1155. 

[0040] In step 1155, the section manager 405 deter- 
mines if there is another AUA 1 56 to examine in this sec- 
tion. If so, then method 1100 returns to step 1125. Oth- 
erwise, the section manager 405 in step 1165 generate 10 
page definitions for the section based on the template 
150, the universal addresses (URLs) and the annota- 
tions (i.e., the results of the examinations performed by 
the modules 407). Step 1165 further includes the step 
of instructing the browser 1 42, 1 58 to generate web pag- is 
es based on the page definitions (which includes down- 
loading the objects identified by the universal addresses 
in the page definitions). 

[0041] The section manager 405 in step 1 1 70 enables 
the modification of modifiable AUA parameters (not 20 
shown) such as privacy levels. The section manager 
405 in step 1 1 75 enables selection of a different section. 
If the section manager 405 in step 1 1 80 determines that 
parameters have been modified, then the method 1100 
returns to step 1 1 20 to generate the web pages based 2s 
on the new parameters. Similarly, if the section manager 
405 in step 1185 determines that the user has selected 
a new section, then the method 1100 returns to step 
1 1 20 to generate the web pages based on the new sec- 
tion. If nothing has been modified (step 1180) or select- 30 
ed (step 1185), then the section manager 405 in step 
1 1 90 determines if the user has requested logout. If not, 
then method 1100 returns to step 1170. Otherwise, 
method 1100 ends. 

[0042] FIG. 12 is a flowchart illustrating a method 35 
1 200 for generating an AUA 1 34 and for placing the AUA 
134 and transfer script 136 in a content provider page. 
Method 1 200 begins with the AUA generator 1 40 in step 
1205 setting an object-specific universal address or 
URL 305 for particular object information 132. The ob- 40 
ject information associated with the URL 305 may be an 
image, text, an applet, a movie, etc. The AUA generator 
140 in step 1210 enables the content provider 115 to 
define annotations 307, e.g., the expiration data 310, 
the re-exportation data 315, the link data 320, etc. The 45 
AUA generator 1 40 in step 1 21 5 generates an AUA 1 34 
based on the object-specific URL 305 and the annota- 
tions 307. An example AUA 134 is shown in FIG. 3. 
[0043] The AUA generator 1 40 in step 1 220 provides 
context data in which the object information 1 32 will re- so 
side. For example, if the object information 132 defines 
a picture of a car, the context data may include text that 
explains the picture or other context data. The AUA gen- 
erator 140 in step 1225 generates a AUA button, such 
as the ADD buttons 520 and 530 illustrated in and de- ss 
scribed with reference to FIG. 5. Although method 1100 
is being described with reference to buttons, one skilled 
in the art will recognize that any request interface such - 



as a pull-down menu, keyboard entry, mouse event, etc. 
may alternatively be used. The AUA generator 140 in 
step 1230 associates the AUA 135 generated in step 
1215 with the AUA button generated in step 1225. It will 
be appreciated that one or more AUAs 1 34 may be as- 
sociated with an AUA button. The AUA generator 140 
in step 1235 generates a content provider HTML data 
which includes the object information 1 32, the URL, the 
context data and the AUA button. It will be appreciated 
that, when a user via a browser 1 42 contacts th e content 
provider 115, the content provider 115 downloads the 
content provider HTML data. It will be further appreciat- 
ed that the browser 1 42 uses the HTML data to generate 
a content provider web page, as illustrated in FIG. 5. 
Method 1200 then ends. 

[0044] It should be understood that, although the fol- 
lowing example is described in terms of a transfer func- 
tion for a diary, the transfer function described can be 
used in any circumstances where a first machine (such 
as system 106) sends data (e.g., third party content) to 
a second machine (such as system 102), and the data 
then needs to be send to a third machine (such as sys- 
tem 104) under control of an applet executing in a 
browser on the second system. The present invention 
is contemplated to be of use in non-diary applications, 
as will as in diary applications. 

[0045] FIG. 16 shows an overview of a first embodi- 
ment of a data transfer function involving three ma- 
chines. Fig. 17 shows an overview of a second embod- 
iment of a data transfer function, also involving three 
machines. Fig. 1 6 will be discussed first. In step 1 of Fig. 
16, the user system 1602 loads the content provider's 
HTML page from the content provider 1 606. This HTML 
page includes a function "F" 1607 that can be activated 
by the user via the HTML page (for example, clicking on 
a "add" button on the page). The user looks at the con- 
tent provider's page (as displayed by the browser) and 
determines whether there is any third party content on 
the page available for his diary that he wants to add to 
his diary. If so, the user so indicates. For example, in the 
described embodiment, the user clicks on an "add" but- 
ton 520 on the HTML page (see Fig. 5) associated with 
the desired third-party content. Clicking on this content 
activates function "F" '1607 within the displayed web 
page, as shown in step 2 of Fig. 16. In the described 
embodiment, function *F* is in JavaScript, but it can be 
any appropriate form of executable program. 
[0046] As shown in step 2 of Fig. 16, the function "F" 
pops up a window 1605 that asks the user for his name 
and for the location of the diary server 1604 (step 3). 
Function *F" needs the name/exact location of diary 
server 1604 so that he can generate HTML page 1608 
(step 4) that requests the transfer applet 1 609 from the 
correct diary server 1 604. (Note that certain embodi- 
ments can have more than one diary server 1604). 
[0047] In step 4, the function "F" also generates HTML 
1608 that contains: 
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1 ) activation of a transfer applet (to be loaded from 
the diary server 1604) (step 4 and 5), and 

2) the parameters of the transfer applet containing 
ail information about the provided content. 

[0048] Thus, function *F B knows how to generate the 
HTML to activate the transfer applet (at the host stored 
by the user) with the parameters of the information to 
store 

[0049] In step 5, function "F" instructs the user 1602, 
i.e., the browser thereon, to load the HTML page 1608 
in a new HTML-browser window. By loading that page 
1608, the browser will load and execute the transfer ap- 
plet 1609 on system 1602 (step 6). When transfer applet 
1609 executes, it transfers data to system 1604. The 
function "F" uses a priori knowledge about the name/ 
exact location of the transfer applet on diary server 
1604. Similarly, function "F" uses a priori knowledge 
about the names and semantics of the parameters re- 
quired by the transfer applet 1609. 
[0050] It is important to note that, due to a security 
restrictions common to many implementations of exe- 
cution environments of programs such as Java applets, 
transferring data between three machines (1602, 1604, 
1606) is problematic. Because the data eventually has 
to be stored on system 1604, because communication 
may have been to be set up with the diary applet already 
running on the system 1602, and because the diary ap- 
plet was loaded from system 1604, the transfer applet 
1 609 also must be loaded from system 1 604. The prob- 
lem is how to get the information describing the content 
provided to the transfer applet 1 609 if the transfer applet 
is to be loaded from server 1 604. For instance, the trans- 
fer applet 1609 is not allowed to connect to the content 
provider system 1606. The problem is solved by gener- 
ating the HTML page 1608, which contains the instruc- 
tions that activate the transfer applet 1609 in combina- 
tion with all information about the content provided that 
should be handled by the transfer applet 1609. In other 
words, the HTML page 1608 is self-contained and the 
transfer applet 1 609 activated by it can handle the trans- 
fer without any other communication other than with its 
source system 1604, which is allowed since it was load- 
ed from system 1604. Thus, the method shown in Fig. 
16 solves the problem caused by the security restraints 
of the execution environment. 

[0051] In at least one embodiment, the database is 
not really transferred immediately, but is only scheduled 
for storage. A running diary applet performs the actual 
storage. If there is no running diary applet in the browser 
on the user system 1602, the transfer applet will start 
one. Similarly, in at least one embodiment, all applets 
store to a "store queue.' This way, the transfer applet 
1609 can insert a database in the queue that will be 
processed by another diary applet. Sharing of the new 
content (as transferred by the transfer applet) with the 
diary applet is extremely important because the new 
content will have to be made visible by the diary applet 



immediately and efficiently, e.g., it would not be accept- 
able to if it would require a user action in order to view 
the new content. Similarly, it would not be acceptable if 
it would require a full "re : upfoad" of the diary information 
s by the diary applet in order to view the new content. The 
underlying fundamental mechanism on which the shar- 
ing has been based is the sharing of class variables in 
a single Java virtual machine. 

[0052] This document includes a JavaScript that per- 

10 forms the function of function "F" of Fig. 1 7. 

[0053] Fig. 17 shows an alternate embodiment of a 
transfer function in which the function "F" does not have 
a priori knowledge about the name/exact location of the 
transfer applet 1609. It can be advantageous to have 

15 function "F" not know the name/exact location of the 
transfer applet. Because there are many function "F"s 
in the network - each content provider 1 606 has HTML 
containing a version of function "F B ~ it can be problem- 
atic if the diary server 1 604 decides to change the name 

20 of the transfer applet 1609. If each function "F" (which 
resides on the content provider(s) 1606) knows the 
name of the transfer applet 1609, each function "F" 
would have to be changed if the name/location of the 
transfer applet 1 609 is changed. If the function "F" does 

25 not know this information, function "F" does not have to 
change if the name of the transfer applet 1609 stored 
on system 1604 changes. 

[0054] In Fig. 17, function "F" (received from system 
1606) pops up window 1605 as described above and 
30 creates a "network package" 1610 that contains at least: 

. - the name of the server 1604; 
the name of the user; and 
the properties of the content to be transferred. 

35 

Network package 1 61 0 is POSTed to diary server 1 604. 
Diary server 1604 builds the page 1608 using the infor- 
mation in the network package 1610 and returns it to 
function "F" in system 1602. Function "F° continues as 
40 in Fig. 1 6. Specifically, function "F" instructs the browser 
thereon to load the HTML page 1608 in a new HTML- 
browser window. From this point onwards, the embodi- 
ment of Fig. 17 behaves as the embodiment of Fig. 16. 
[0055] It will be appreciated that in this embodiment, 
45 the a priori knowledge of function "F" is limited to only 
the way the network package 1610 is to be structured, 
the content that is to be put into network package 161 0, 
and the way this package 1610 is to be sent to diary 
server 1604. The amount of knowledge required is less 
50 than the knowledge required to generate page 1 61 0 it- 
self (as it does in the embodiment of Fig. 16). 
[0056] It will be appreciated that the embodiment of 
Fig. 17 limits the "outer world" restrictions on the inter- 
face of diary server 1604. Once the diary server 1604 is 
55 in operation (as illustrated in Fig. 1 7), it should always 
support the handling of network packages 1610. How- 
ever, the internals of page 1 608 may be changed by the 
diary server 1604 whenever such a change is required. 
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Note that such a change is not an option in the embod- 
iment of Fig. 16, since the a priori knowledge about the 
contents of page 1608 have been spread over numer- 
ous content provider systems 1606. 
[0057] The destination section of each entry in the 
current transfer may be changed by selecting the entry 
and then selecting a section. That is, the transfer applet 
1609 will pop up a window as shown in FIG. 8 from which 
the user will be able to select a destination section from 
the named sections that exist in the diary. Similarly, the 
user can delete entries that he is not interested in, and 
move entries to between section. The transfer applet 
1609 will add the entries to the AUA-database in the us- 
er diary data 122 as requested. In one embodiment, 
transfer applet 1609 issues a "store" command that is 
queued in the store queue and checks whether a diary 
applet is already running. If no diary applet is running, 
the transfer applet 1 609 will start a diary applet automat- 
ically. 

[0058] Following this paragraph is example code, in 
this case in the JavaScript™ scripting language, 
of AU As 1 34 and the transfer script 1 36. The example 
code is intended as part of the Specification. It will be 
appreciated that each of the four code paragraphs be- 
ginning with "W3Contenf indicates an AUA. 
[0059] The foregoing description of the preferred em- 
bodiments of the present invention is by way of example 
only, and other variations and modifications of the 
above-described embodiments and methods are possi- 
ble in light of the foregoing teaching. For example, al- 
though the embodiments herein have been described 
with reference to a diary-type system, any system for 
maintaining an ordered set of object locations, annota- 
tions and presentation contexts can alternatively be 
used. Although the network sites are being described 
as separate and distinct sites, one skilled in the art will 
recognize that these sites may be a part of an integral 
site, may each include portions of multiple sites, or may 
include combinations of single and multiple sites. Fur- 
ther, components of this invention may be implemented 
using a programmed general purpose digital computer, 
using application specific integrated circuits, or using a 
network of interconnected conventional components 
and circuits. Connections may be wired, wireless, mo- 
dem, etc. The embodiments described herein are not 
intended to be exhaustive or limiting. The present inven- 
tion is limited only by the following claims. 
[0060] As indicated above, embodiments of the inven- 
tion are not limited to any specific combination of hard- 
ware and software. Where an embodiment includes 
software components, these can form a computer pro- 
gram product. Program instructions could be provided 
on any suitable carrier medium, for example a computer 
readable medium such as a storage medium (e.g. solid 
state memory, optical and/or magnetic media, etc.) and/ 
or a transmission medium (e.g. a carrier wave, tele- 
phone line, wireless link, etc.). 



Claims 

1 . A computer-based method, comprising the steps of: 

5 receiving from a client a request for access to 

an annotated universal address (AUA) data- 
base, which contains at least one AUA having 
a universal address identifying a location of an 
object and having an annotation for controlling 
10 an aspect of the object; 

identifying a presentation context correspond- 
ing to the request; and 

transmitting to the client the presentation con- 
text, the AUA and an applet for generating a 
page definition from the presentation context 
and the AUA. 

2. A system comprising: 

first memory storing a presentation context; 
second memory storing an annotated universal 
address (AUA) database, which includes at 
least one AUA having a universal address iden- 
tifying a location of an object and an annotation 
for controlling an aspect of the object; 
third memory storing an applet for generating.a 
page definition from a presentation context and 
an AUA; and 

means coupled to the first memory and the sec- 
ond memory for receiving an access request 
from a client, and for identifying the presenta- 
tion context and the AUA in response to the ac- 
cess request; 

a web server coupled to the diary software for 
transmitting the presentation context, the AUA 
and the applet to the client. 

3. A computer-based method, comprising the steps of: 

requesting access to an annotated universal 
address (AUA) database, which includes at 
least one AUA having a universal address iden- 
tifying a location of an object and including an 
annotation for controlling an aspect of the ob- 
ject; 

receiving the AUA from the AUA database in 
response to the request; 
receiving a presentation context from a presen- 
tation context server in response to the request; 
generating a page definition using the presen- 
tation context and the AUA; and 
retrieving the object specified by the universal 
address. 

55 4. A computer-based method, comprising the steps of: 

assigning a universal address to a location of 
an object; 
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generating an annotation for controlling an as- 
pect of the object; 

associating the universal address with the an- 
notation to generate an annotated universal ad- 
dress; 5 
associating a request interface with the anno- 
tated universal address; 
generating network data for presenting the ob- 
ject and the request interface; and 
enabling transfer of the annotated universal ad- io 
dress upon receiving an indication at the re- 
quest interface. 

5. A system comprising: 

75 

means for assigning a universal address to a 
location of an object; 

means for generating an annotation for control- 
ling an aspect of the object; 
means for associating the universal address 20 
with the annotation to generate an annotated 
universal address; 

means for associating a request interface with 
the annotated universal address; 
means for generating network data for present- 25 
ing the object and the request interface; and 
means for enabling transfer of the annotated 
universal address upon receiving an indication 
at the request interface. 

30 

6. A computer-based method, comprising the steps of: 

requesting addition of an annotated universal 
address (AUA) to an AUA database on a serv- 
er; 35 
receiving a transfer script in response to the re- 
quest; 

initiating execution of the transfer script to re- 
quest a transfer applet from the server; and 
initiating execution of the transfer applet to 40 
transfer the AUA to the AUA database on the 
server. 

7. A system comprising: 

45 

third party memory storing a transfer script that 
generates a request for a transfer applet from 
server memory; 

server memory storing a transfer applet for es- 
tablishing a communications link between a cli- so 
ent browser and the server memory; and 
a client browser coupled to the third party mem- 
ory and to the server memory for executing the 
transfer script and the transfer applet. 

55 

8. A computer program product for carrying out the 
steps of a method according to any one of claims 
1,3, 4 and 6. 
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